1. Technical Field
This invention relates generally to secure and reliable transmission of data. More particularly, the invention relates to computer-implemented techniques for securely and reliably transmitting an electronic document along a routing list using a secure, central key managing intermediary.
2. Background Art
With the advent of computers and the Internet, an increasing number of documents is being transmitted in electronic format between an increasing number of recipients, and there is a growing acceptance of the electronic delivery of documents. For example, many companies transact business through the use of documents, such as contracts, memos, emails, etc. In order to transact business, these documents often are circulated for approval or review. As a result, it is becoming increasingly important to be able to deliver these documents in a secure and reliable manner. It is also becoming increasingly important for the delivery service to be flexible in order to handle more complex distribution and routing lists.
While unsecured email is perhaps one of the most common electronic delivery methods, it typically is not secure, flexible or particularly reliable. Other approaches to electronic delivery exist which are more successful in attempting to provide either secure or reliable delivery of documents. Two of the more common approaches are secure electronic mail (a.k.a., secure email) and Secure Socket Layer (“SSL”) based deliveries using a Web site for uploading and downloading of deliveries. However, neither of these delivery methods is fully satisfactory with respect to security or reliability and generally is no better than unsecured email with respect to flexibility.
Secure email is similar to unsecured email, except that email messages are secured using encryption. In unsecured email, the sender transmits his message to the recipient in an unencrypted state. Thus, if a third party intercepts the message en route to the recipient, the third party will be able to read the message. In secure email, the sender first encrypts the message using a key and then transmits the encrypted message to the recipient. If a third party intercepts this message, it will be unintelligible to the third party since he presumably does not have enough information to decrypt the message (e.g., the third party normally does not have the correct key required to decrypt the message). The recipient, on the other hand, does have the information required to decrypt the message and therefore can read the message when he receives it. By limiting access to the decryption method and keys, the sender can limit who is able to read an encrypted message. By encrypting the message before transmitting, the message is protected during transmission.
However, secure email is delivered from the sender to the recipient using the same architecture and infrastructure as unsecured email and, therefore, suffers from many of the same drawbacks as unsecured email. For example, secure email delivery services generally lack reliability due to the architecture of the email delivery system and are limited to the same types of distribution as unsecured email. Conventional email servers are designed upon a store-and-forward architecture. An email message may be routed through several email servers on its way from the sender to the recipient, with each server receiving the incoming message, determining the next server on the message's journey, transmitting the message, and possibly leaving behind a copy causing unnecessary and unmanageable audit trails. No single machine is responsible for ensuring that the entire message has been successfully transmitted from the sender to the recipient. In addition, each of the email servers in the chain from sender to recipient is usually owned and operated by a different party. Since no single company or entity owns the entire delivery chain for the email message, no one company or entity can guarantee reliable delivery or integrity of the message. The storing-and-forwarding of email documents through several servers owned by multiple parties means that email messages get lost, delayed, and corrupted. This makes the overall delivery service unreliable or untrackable, and this is just in the context of a delivery from one sender to one recipient. These problems are aggravated if the document is to be routed among multiple recipients, for example along a routing list over the Internet. Encrypting an email message may provide some protection against unwanted disclosure during transit, but it does not address the reliability issue, does not guarantee that the message will be delivered to the recipient, and does not provide the flexibility to support more sophisticated routing lists with end to end tracking.
An alternate approach to document delivery services utilizes the Secure Socket Layer Protocol for security. In this approach, a Web site uses its digital certificate to authenticate itself to the sender using the SSL protocol. Once the Web site is authenticated, a secure channel is set up between the sender's browser and the Web site, typically by generating a session key to encrypt transmissions between the two. The document is sent from the sender's browser to the Web site via the secure channel. It is stored at the Web site, typically in unencrypted form, awaiting delivery to the recipient. During delivery, the Web site authenticates itself to the recipient's browser and a secure communications channel is then set up between the Web site and the recipient's browser. The document is delivered to the recipient via the secure channel.
The SSL approach suffers from many drawbacks. For example, although the Web site authenticates itself using its digital certificate, neither the sender nor the recipient authenticates himself using a digital certificate. Typically, these systems would at most require the sender and the recipient to authenticate themselves using passwords, which is weak security. In other words, there is no real assurance that either the sender or the recipient actually is who he claims to be. As a result, there is also a lack of non-repudiation, meaning that at a later time, the sender can plausibly deny having sent the document simply by pointing out that there is no strong evidence of who actually sent the document.
Another drawback is that these systems lack end-to-end security, because SSL secures only the channels. The document typically remains in unencrypted form while it is temporarily stored at the Web site. Hence, a third party which attacks the Web site and gains access to the document will be able to read the document. In addition, if the Web site is untrustworthy (or happens to hire an untrustworthy employee), the document will be vulnerable.
There are also SSL-based services that provide optional password encryption of the documents. These systems provide better security, since the document is encrypted at the point of transmission. However, these systems are difficult to use since they require the sender to communicate the password out-of-band to the recipient, a process that is cumbersome and fraught with security risks. Such a system also does not guarantee non-repudiation, since it neither strongly authenticates a user, nor supports digital signatures, nor ensures that only the recipient could open a delivery.
There are also SSL-based services that provide optional encryption of the documents using certificates. These systems provide end-to-end content security, but are extremely difficult to use because of the need for users to manually obtain the keys and exchange keys prior to encryption. Unfortunately, these systems do not integrate key management with encryption and reliable delivery, leaving the complexity of key management entirely to the user. In addition, a system that requires optional use of certificates cannot guarantee non-repudiation. The absence of a digital signature does not represent the absence of a transaction, because the sender could have opted to not use a certificate. Absolute non-repudiation requires mandatory and uniform use of certificates for all transactions in a system.
Finally, the SSL approach, like secure email delivery services, is typically focused on delivering documents from one sender to one recipient(s). As a result, more complex deliveries, such as those using routing lists, can be difficult to implement. For routing lists to be effectively implemented, deliveries should be tracked end to end. In this way, the progress of a delivery along the routing list can be tracked and the delivery can be correctly routed to the next recipient(s). Secure email services typically cannot implement end to end tracking for the reasons discussed above. In addition, to facilitate business-to-business routing of documents over a public network such as the Internet, strong security is often a requirement. SSL services typically cannot provide strong security. Neither the SSL approach nor the secure e-mail approach currently provides sufficient security and reliability to facilitate a robust implementation of routing lists over public networks.
In contrast, existing workflow systems can facilitate the routing of documents between various recipients but they typically are limited to internal communications and cannot be used securely or reliably to communicate with the outside world. Typically, a workflow server stores a document online and decides who should get the document next and notifies the next recipient to come and get it. One example of such a workflow system is Lotus Notes, in which documents and forms are database driven and the next recipient is notified once certain prior conditions, as determined by a central server, are met. These systems typically require that all of the recipients have access to a common database or common software. However, companies are reluctant to store their documents in databases which are widely accessible from the outside due to security concerns. Alternatively, the routing rules can be embedded as part of the delivery but proprietary software is required to decipher and execute the embedded rules. This approach is not suitable for use between different companies because companies typically are not willing to install common software just to facilitate workflow with one of its business partners. Thus, in practice, current workflow systems are confined to well-defined, closed communities.
Therefore, there is a need for a flexible delivery system which provides integrated key management so that reliable delivery and end-to-end security can be achieved, thus providing some or all of the following benefits: (1) reliable/guaranteed delivery for transactions—a delivery will not be lost; (2) confidentiality for transactions—only the recipient can open a delivery; (3) non-repudiation for transactions; and (4) complex routing of transactions among multiple recipients, including over the Internet between different organizations.